Dan Stromberg wrote: > > On Fri, 24 May 1996, Matthew Harding wrote: > > > Note that this is a registered bugid with Sun (1222940) but > > it is marked closed with no patch. Why? Because Sun's > > solution for SunOS 4.1.x is to remove permissions from > > /dev/openprom for unprivileged users, without actually fixing > > the problem. No comment on this approach to "security"... > > 1) 1.x is dead. They'd be shooting themselves in the foot to fix this > kind of problem in 1.x. No kidding it's dead. But notice how the sendmail patches are all backported to 4.1.x? Just because it's dead doesn't mean they can't do backwards support. BTW, SunOS 4.1.3 and above is still officially supported... customers have a right to expect patches for supported OSs. > 2) The problem is infinitesimal in 2.x. (see #5, below) I don't believe the ability to panic a system by reading the /dev/openprom device is infitesmial. But that's a moot point. > 3) If you chmod the file under 1.x, treat as #2, above. Same comments apply. The hole is still there, even if you chmod it out. Ever upgraded an OS and found out that file permissions were all reset back to the originals from the media...? > 4) One might argue that they should issue a patch for 1.x, > consisting of nothing more than a README that says "chmod > 640 /dev/openprom". There is actually a SunOS 4.1.x patch that does exactly this, patch# 100103. From the description: " File permissions on numerous files were set incorrectly in the build tape of 4.1.x FCS. This script changes them back to what they should be. " However, it hasn't been updated since 1993. > 5) It makes vastly more sense for sun (or or any other OS development > team) to spend time on new features, instead of fixing "problems" where > priviledged users "can" crash their own machines (/oh boy! I get to > crash a machine I'm responsible for!/). Consider: > > dd if=/dev/zero of=/dev/dsk/c0t3d0s1. > > This is a generally bad thing to do, but I sure don't want _any_ vendor to > waste time disallowing dd'ing to certain partitions. (If someone tries out > that dd command, I'm not responsible for the results.) You're missing the point. Of course there are commands you can perform that will crash your system... how about my favourite, rm -rf /. The point is that this is operating _AS DESIGNED_. The ability to panic a system by merely reading the openprom is an error in implementation, not design. And should be fixed (in my opinion). > It's helpful to fish around for bugs, no matter what their significance, but > it is more helpful if one also maintains a sense of where these bugs > fit into the overall picture, which is: setting up operating systems that > allow users to get things done. This should include minimizing > boobytraps waiting for sysadmins, which result in downtime for users - > but even that doesn't really apply in this case. Agreed. And the point I was making is that all sunos 4.1.x boxes (including 4.1.4) is a waiting time bomb... And the fact that bug crosses all the way from 4.1.x up to and including Solaris 2.5 bothers me... I'm glad you're not worried about it. > BTW, I just added a "chmod 640 /dev/openprom" to our SunOS 4.1.x > autoinstall environment. Any new 4.1.4 boxes we set up (very few), will > have this fixed automatically. As I said, there is a patch from Sun ostensibly to do just this, but it wasn't updated with this or other "permission" problems. But keep in mind that this is a flaw in design, whether masked by permission changes or not. For people running firewalls under SunOS 4.1.x (and there's a lot of you!), keep this in mind. I think we've beaten this to death... any other comments not germane to this disclosure, please email me offline. Cheers, Matthew (matt@ott.opcom.ca)